Day 2｜後面的提示詞，不一定改比較兇

第 0 天一個下午，十一句提示詞把迷你商店蓋起來，速度快到有點上癮。回頭看那張 prompts.md，卻說不清楚：是真的越用越順，還是後面幾句剛好功能比較複雜？我沒有團隊、也沒有兩週衝刺可以對照，只有一個人、這一場的第一手紀錄。今天要問的很窄：提示詞序號往後走時，改動量是不是跟著不成比例變大。

這跟哪一本書有關？

這個問題來自 Peter Isberg 的 《Vibe Coding Architecture at Scale》（Packt，第一版，2026）第 1b 章〈The Jevons Effect〉。

第 1b.1 節先從 Jevons 在 1865 年出版的《The Coal Question》談起：蒸汽引擎用煤更有效率，英國的煤炭總消耗量卻沒有跟著下降。第 1b.2 節再把這個觀點放進 AI 輔助開發：寫功能的成本下降，不代表待辦會清空，產品需求反而可能擴張。

這是作者提出的類比，不是 vibe-order 已經證明的現象。我把它縮成一個今天能量的問題：同一場開發裡，提示詞序號愈往後，每次存檔的改動量有沒有跟著變大？我手上沒有團隊待辦長度，只有第 0 天留下的提示詞紀錄與 Git 歷史，所以用改動行數當替代指標。這兩者不能畫上等號，只能拿來找初步線索。

這篇要量什麼

用可重跑的方法量出「同一場裡，提示詞位置與改動量的關係」，再拿結果回答一個較小的問題：這份單人樣本是否出現符合第 1b.2 節推論的訊號？它不是對 Jevons 效應或原書主張的驗證。

為什麼用 day0 留下的存檔

直接重用 day0/prompts.md 已經留下的時間戳與一次存檔（commit），不額外裝追蹤工具。能對到存檔的，用該次 git show --numstat；對不到的才退回時間戳分段。數字對得上第 0 天那份紀錄，不是另立一套統計口徑。原章談的是團隊產能、需求數量與待辦清單長度；我這一天量不到那些，改動行數只是目前僅有、可重跑的替代指標。

產出了什麼

scripts/diagnose/prompt-diff-stats.mjs 與 reports/day2-jevons-check.md。第二次乾淨量測的前五列大致是：第 1 句 4263 行、27 檔；第 2 句 18 行；第 3 句（忠誠點數）18 行、4 檔；第 4 句 35 行；第 5 句 21 行。前後半段平均：前半（序 1–5）871.0 行，後半（序 6–11）31.7 行，比值 0.04。後半比前半更小。

老實講：第 1 句 4263 行裡，光 package-lock.json 就佔 3818 行，把前半平均拉高了。若拿掉第 1 句，後半對上序 2–5 的另一種讀法大約是 1.38，這只是旁註，不能當結論。

先紅後綠，再重跑

npm run diagnose:jevons。第一次十一句全記 0 行：prompts.md 的存檔欄帶反引號，git 認不得 `f7a9f13`。腳本改成剝掉反引號後再跑，沒有改分組方式，也沒動 packages/。第二次才拿到上表。從紅到綠兩輪。

故意埋的陷阱句對到 8 條。第 3 句忠誠點數 18 行、4 檔；第 7 句地區稅率 12 行、1 檔。原本以為後面會改得比較兇，尤其地區稅率聽起來會踩到結帳櫃台，結果只動 12 行、1 檔。陷阱句沒有變成「後面比較兇」。

做不到的事

原章討論的是團隊層級的產能、待辦與需求擴張，我的樣本卻只有第 0 天一天、一個人，層級並不相同。比值是 0.04，後半更小，本來就沒有「後面不成比例變大」的訊號。就算曲線往上，也分不出「後面功能本來就比較複雜」與「成本下降後需求擴張」兩種原因。這篇只能當假說的初步線索，不能拿來坐實原書或 Jevons 效應。

來源與 AI 使用揭露

概念來源：Peter Isberg，《Vibe Coding Architecture at Scale》（Packt，第一版，2026），第 1b 章〈The Jevons Effect〉。今天採用兩段內容：1b.1 說明煤炭效率悖論；1b.2 討論 AI 提高產能後，待辦與需求可能繼續擴張。1b.3 談結構風險，1b.6 談如何讓護欄追上生成速度，這兩節留給系列後續實作，不能用今天的數字下結論。出版社的書籍介紹與書目資料可供核對。

AI 使用揭露：統計腳本由 AI 依寫作卡生成，我逐條核對；一次存檔的反引號是我修的；量測數字為我親測，樣本量小。程式與報告是 vibe-order 實驗產物，不是原書附的範例碼。

下一篇預告

明天換個角度看同一批第 0 天紀錄：加地區稅率那句提示詞下去之後，看起來乾淨、測試也過的程式裡，會不會其實藏著肉眼看不出來的稅率缺口。